Photo de 
Photo de La semaine dernière, Wedson Almeida Filho, l'un des principaux collaborateurs du projet Rust for Linux, a décidé d'arrêter de travailler sur l'intégration de ce langage dans le noyau libre. En cause, son « manque d'énergie et d'enthousiasme » face à des problèmes qui, selon lui, relèvent d' « absurdités non techniques », confirmant les difficultés de relations humaines qui entourent la gestion du noyau Linux.
Wedson Almeida Filho, l'un des responsables de l'équipe chargée d'encadrer l'utilisation du langage Rust dans le noyau Linux, a annoncé son départ la semaine dernière sur la liste de discussion du projet. Cet ingénieur de Microsoft explique qu' « après presque 4 ans, [il n'a] plus l'énergie et l'enthousiasme qu'[il avait] autrefois pour répondre à certaines des absurdités non techniques ».
Ce langage est de plus en plus utilisé dans des projets critiques pour assurer une gestion de la mémoire plus robuste. La DARPA l'utilise par exemple, ayant pour ambition d'éliminer « une fois pour toutes les vulnérabilités liées à la sécurité de la mémoire » et a même lancé un projet pour traduire automatiquement le code C en Rust. La Maison-Blanche exhorte même les développeurs à se mettre au Rust.
Une intégration qui prend du retard
Débuté en 2020, le projet Rust for Linux a pour ambition d'aider à augmenter encore la sécurité du noyau le plus connu du logiciel libre. En avril 2021, travaillant alors dans l'équipe Android de Google, Wedson Almeida Filho affirmait dans un billet de blog : « nous pensons que Rust est maintenant prêt à rejoindre le langage C en tant que langage pratique pour l'implémentation du noyau. Il peut nous aider à réduire le nombre de bugs potentiels et de vulnérabilités de sécurité dans le code privilégié, tout en s'intégrant proprement avec le noyau central et en préservant ses caractéristiques de performances ».
Mais il a fallu attendre fin 2023 pour que le langage s'insère pour la première fois dans la version 6.8 du noyau via un driver réseau, comme l'expliquent le chercheur Hongyu Li et ses collègues, dans une étude de l'intégration du langage dans le noyau publiée début juillet. Linus Torvalds, le créateur de Linux et toujours responsable de son développement, avait pourtant annoncé cette intégration pour la version 6.1.
Altercation virulente entre développeurs C et Rust
Mais ce retard ne mine pas la confiance de Wedson Almeida Filho dans l'utilité de Rust pour écrire des noyaux robustes. Au contraire, il affirme dans son message : « je crois vraiment que l'avenir des noyaux passe par des langages à mémoire sécurisée ». Il ajoute même que Linux pourrait se faire dépasser par d'autres noyaux : « je ne suis pas un visionnaire, mais si Linux n'intériorise pas cela, je crains qu'un autre noyau ne lui fasse ce qu'il a fait à Unix ».
Wedson Almeida Filho intègre aussi dans son message un lien vers une vidéo filmée en mai lors de la conférence Linux Storage, Filesystem, Memory-Management, and BPF Summit. Le passage qu'il pointe montre une discussion difficile entre l'ingénieur et un de ses collègues, Ted Ts'o, qui l'accuse de vouloir « convaincre tous les autres de s'orienter vers une religion promue par Rust ».
« Et la réalité, c'est que ça ne va pas arriver, car nous avons plus de 50 systèmes de fichiers dans Linux qui ne vont pas être convertis immédiatement en Rust. Avant ça, nous allons continuer à réécrire du code C, car nous voulons que le code en C soit meilleur », argumentait le second. Il avait ajouté : « vous n'allez pas tous nous forcer à apprendre Rust ».
Des développeurs Rust solidaires
Comme l'a repéré ArsTechnica, la développeuse Asahi Lina (responsable du projet Asahi Linux) a partagé un avis similaire à celui de Filho en le soutenant : « je comprends malheureusement tout à fait les frustrations de Wedson ».
Elle évoque son expérience lorsqu'elle a voulu proposer des modifications au Direct Rendering Manager(DRM) de Linux : « lorsque j'ai essayé d'apporter en amont des corrections mineures au code C pour rendre le comportement plus robuste et les exigences de durée de vie plus raisonnables, le mainteneur l'a bloqué et a dit que je devais simplement faire "ce que font les autres pilotes" ». Elle ajoute qu' « un sous-ensemble de développeurs du noyau C semble déterminé à rendre la vie des mainteneurs de Rust aussi difficile que possible ».
« À ce jour, des bugs dans l'ordonnanceur du DRM ont été les seules causes de kernel panics déclenchées par le pilote de mon GPU Apple en production [...] », explique Asahi Lina, « parce que je code en Rust ».
Dans un billet de blog, Drew DeVault, le fondateur de la plateforme d'outils open source Source Hut, suggère aux développeurs Rust de développer un noyau compatible Linux à partir de zéro. Ceci devrait, selon lui, les libérer des batailles politiques des mailing lists du noyau Linux. Celles-ci seraient plus un « far west » qu'un milieu « enthousiaste et prêt à accueillir en son sein des innovateurs motivés pour faciliter cet impact ».
Constat désemparé de Linus Torvalds
Ce n'est pas le premier conflit interpersonnel à surgir dans le projet du noyau Linux. Linus Torvalds a lui-même installé pendant longtemps un climat brutal dans ses conversations, qu'elles soient internes ou externes. En 2018, il avait envoyé un message d'excuses.« Je vais prendre du temps pour moi et demander de l’aide pour comprendre les émotions des autres et comment y répondre de manière appropriée », annonçait-il.
Torvalds expliquait à Zdnet au mois d'aout : « je m'attendais à ce que les mises à jour soient plus rapides, mais le problème réside en partie dans le fait que les développeurs de noyau de longue date sont habitués au C et ne connaissent pas Rust. Ils ne sont pas vraiment enthousiastes à l'idée de devoir apprendre un nouveau langage qui est, à certains égards, très différent. Il y a donc eu des réactions négatives à l'égard de Rust ». Il ajoutait cependant qu' « une autre raison est que l'infrastructure Rust elle-même n'a pas été très stable ».
L'un des membres de la Rust core team, Steve Klabnik, a commenté sur Bluesky : « des responsables du noyau Linux se comportent si mal que d'autres abandonnent. Windows se contente de livrer discrètement du code Rust. Nous verrons comment tout cela va se dérouler… »
Commentaires (44)
#1
#1.1
#1.2
#1.6
#1.3
#1.4
#1.5
#1.9
#1.7
#1.8
#2
Autant dans le premier cas, je peux comprendre la frustration de devoir passer son temps libre à apprendre, autant dans le second, c'est juste... puéril. En choisissant de bosser dans l'informatique, on accepte une formation continue, sinon autant bosser en Cobol pour une grosse banque.
#2.1
Pour la formation continue, ils bossent dans le noyau qui demande pas mal de rétrocompatibilité.
Ça doit jouer dans le fait de ne pas évoluer trop vite. C'est pas une nouvelle solution a la mode qui sera abandonné dans 3 ans.
#2.4
Rust a 10 ans passés. Il est maintenant mûr, il a montré de très grandes qualités native sur la sécu, le multitâche, les perfs et la conso de ressources.
Mais je comprends parfaitement l'agacement de la réécriture face à la maintenance. Le risque à réécrire est grand. Et les développeurs noyau ont un sacré égo - donc rust pour la ligne de commande ça ne les dérange pas, mais rust dans les pilotes ça les gêne.
De même, le C, c'est très (très très) proche de l'assembleur - on a l'impression de piloter hyper finement, de maîtriser, là ou rust n'est pas aussi transparent.
Par contre rust implémente certains concepts comme le parallélisme et le SIMD via des librairies de base et la syntaxe normale, pour le C c'est franchement de l'extension et ça sent bon la verrue depuis toujours par exemple.
#2.7
#2.10
Non, Rust n'est pas mur. Son ABI n'est pas encore très stable dans le temps et il évolue encore trop vite pour parler de maturité. Pour faire des codes qui vont être oublié dans le user-space, pourquoi pas. Mais pour un kernel (je parle pas des drivers), Rust va demander une plus grande maintenance de par ses futures évolutions.
Sur la sécu mémoires uniquement, Rust est en effet assez novateur.
Pour la partie perf, en monocoeur Rust est moins bon que le C compilé avec GCC en raison de LLVM, idem pour la partie conso des ressources. Mais ça reste à la marge en général. Par contre niveau du temps de compilation assez délirants pour être devant être mur.
Pour le multitâche, Rust est pas mal pour de la mémoire distribuée, il ne fait guère mieux que le C. Mais en mémoire partagées, sa manie de tout copier ou de mettre des verrous partout le rendent moins rapide que le C.
Par contre rust implémente certains concepts comme le parallélisme et le SIMD via des librairies de base et la syntaxe normale, pour le C c'est franchement de l'extension et ça sent bon la verrue depuis toujours par exemple.
Vrai question. Tu trouves le parallélisme sous Rust plus facile ? Déjà que la syntaxe de Rust est son plus gros défaut (à ce niveau même l'API de Windows est plus lisible) mais pour piger le calcul parallèle en Rust c'est juste infect. Trop verbeux, trop syntaxe inutilement cryptique. Pour le SIMD en Rust, c'est la même chose en plus de nécessiter de l'unsafe et devoir écrire de l'assembleur haut-niveau.
Alors, le parallélisme en C, ça peut vite devenir dégeu. Je suis d'accord. Mais le SIMD en C, non c'est clairement plus lisible qu'en Rust.
Et pour les deux, les libraires sont natives (i.e., fournit avec le compilateur).
#2.15
Dans le contexte de Rust for Linux, l'ABI n'est pas un problème. en effet le code Rust devant interagir avec du C, il utilisera l'ABI C qui est stable.
#2.16
Mais dans ce cas, pourquoi s'embêter à maintenir deux langage ensemble si l'un des n'est qu'un wrapper ? J'en vois pas l’intérêt, et qui plus Rust est a une courbe d'apprentissage assez raide par rapport à du C.
Par contre, et c'est un scénario qui va arriver dans le futur si Rust reste, quid des fonctions codés en Rust vont devoir se brancher avec du C durant la migration de pans du kernel de C-> Rust ?
#2.17
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera pas avant de très très longues années, si jamais ça arrive, D'ici à ce que la question de généraliser l'usage de Rust se pose, Rust aura probablement déjà une API stable (il y a des travaux en cours).
Je pense qu'une grosse partie des problèmes actuels viennent de cette incompréhension. Le projet Rust for Linux n'a pas assez communiqué sur la limitation du scope de Rust. Certains ont eu l'impression que le but du projet était de tout réécrire en Rust.
Historique des modifications :
Posté le 08/09/2024 à 07h47
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que l'écrasante majorité des problèmes de qualité viennent des drivers.
Penser à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longes années, si jamais ça arrive, D'ici là les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Posté le 08/09/2024 à 07h50
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici là les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Posté le 08/09/2024 à 07h52
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici là les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Posté le 08/09/2024 à 07h55
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici là les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Posté le 08/09/2024 à 07h56
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici que la question se pose, les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Posté le 08/09/2024 à 08h01
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici que la question se pose, les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Je pense qu'une grosse partie des problèmes actuels viennent de là. La projet Rust for Linux n'a pas assez communiqué sur la limitation de leur scope et certains ont eu l'impression que le but final du projet était de tout réécrire en Rust.
Posté le 08/09/2024 à 08h06
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici que la question se pose, les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Je pense qu'une grosse partie des problèmes actuels viennent de là. La projet Rust for Linux n'a pas assez communiqué sur la limitation de leur scope et certains ont eu l'impression que le but du projet était de tout réécrire en Rust.
Posté le 08/09/2024 à 08h31
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici que la question se pose, les travaux actuels pour produire une ABI Rust stable auront probablement abouti.
Je pense qu'une grosse partie des problèmes actuels viennent de là. Le projet Rust for Linux n'a pas assez communiqué sur la limitation de leur scope et certains ont eu l'impression que le but du projet était de tout réécrire en Rust.
Posté le 09/09/2024 à 06h19
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici à ce que la question de généraliser l'usage de Rust se pose, Rust aura probablement déjà une API stable (il y a des travaux en cours).
Je pense qu'une grosse partie des problèmes actuels viennent de là. Le projet Rust for Linux n'a pas assez communiqué sur la limitation de leur scope et certains ont eu l'impression que le but du projet était de tout réécrire en Rust.
Posté le 09/09/2024 à 06h21
Pour le moment, il n'y a aucun plan pour aller au delà de l'écriture de module en Rust qui utiliseront l'ABI C. Si on arrive a avoir un nombre conséquent de drivers disponibles en Rust d'ici quelque années, ça serait déjà un très gros progrès vu que la majorité du code de Linux, c'est les drivers, et c'est la partie qui a le plus de problèmes de qualité.
Penser maintenant à intégrer du Rust dans le cœur de Linux, c'est clairement mettre la charrue avant les bœufs. Ça n'arrivera clairement pas avant de très longues années, si jamais ça arrive, D'ici à ce que la question de généraliser l'usage de Rust se pose, Rust aura probablement déjà une API stable (il y a des travaux en cours).
Je pense qu'une grosse partie des problèmes actuels viennent de cette incompréhension. Le projet Rust for Linux n'a pas assez communiqué sur la limitation du scope de Rust. Certains ont eu l'impression que le but du projet était de tout réécrire en Rust.
#2.2
Faire une revue avec du code illisible (rust reste peu connu), ca nécessite d'engager sa responsabilité.
Bien sûr, je pense qu'il y a un peu de côté puéril genre blessure profonde à l'amour propre: Rust est censé apporter une sécurité par défaut, que les dev on la fierté d'apporter par leur contribution.
#2.3
Paix à vos âmes Silverlight, Flash, Shockwave et probablement plein d'autres (OK, c'est plutôt des technologies que des langages mais c'est l'idée).
#2.5
Rust gagne en popularité, et le noyau Linux aurait certainement à gagner à inclure du Rust. Je ne dis pas le contraire.
Maintenant, il faut se replacer dans le contexte : Linux est un projet qui a 33 ans, qui est constitué de millions de lignes de code, et jusqu'à présent est écrit quasiment exclusivement en C, avec quelques morceaux d'assembleur propre à chaque architecture quand il n'est pas possible de faire autrement.
Rust, bien que présentant des avantages, a aussi des défauts. Le langage dans sa forme actuelle est encore jeune, sa popularité est récente, il a failli tomber après l'abandon par Mozilla en 2020. Il s'est plus ou moins stabilisé ces dernières années.
Sa courbe d'apprentissage n'est pas simple et nécessite un véritable investissement. Le noyau Linux, de part sa nature, nécessite aussi un véritable investissement pour y aller. Pour l'instant, il n'est qu'en C (ou quasiment). Si demain, il faut connaitre à fond et le C et le Rust, cela risque d'en rebuter plus d'un.
Le problème, pour moi, n'est pas tant de décider d'avoir du C ou du Rust, mais de faire cohabiter les deux, avec les soucis que cela peut engendrer. Une base de code, avec un seul langage, c'est quand même bien plus pratique. Comme il y a déjà des millions de lignes de code en C dans le noyau, le C à forcément un avantage certains de ce point de vue.
J'entends certains des arguments avancés par "l'équipe Rust". Mais j'ai l'impression aussi parfois qu'ils font une montagne d'un non-événement et parce que ce qui est présent actuellement ne permet pas à Rust de fonctionner correctement doit être changé (cf. les propos d'Asahi Lina).
Elle interprète ce refus comme des bâtons mis dans les roues de l'équipe Rust, alors qu'il peut très bien s'agir de conserver un comportement et un style de code homogène à travers l'ensemble des drivers. Car un changement, aussi mineur soit-il, quand il y a 50 drivers qui en dépendent, peut facilement créer des incompatibilités ou des effets de bords non prévus dans certains d'entre eux.
Vue la criticité du projet, il me parait plus que normal de ne pas sauter sur l'effet de mode du moment.
#2.6
On comprends aussi la réserve: Tous les 10 ans on nous annonce le langage qui va être le fossoyeur du C qui est toujours là. Pour du bas niveau, avec des développeurs typés logiciel de base qui doivent déjà se fader la complexité croissante du matériel, je pense que tout langage qui en rajoutera sa couche avec en prime une perte de performance, même faible mais là ou elle est vraiment importante, surtout pour le pb très largement réglé de la mémoire, ne fera pas son trou. C'est aussi un domaine ou la chasse aux dépendances est féroce...
Ils mènent un combat côté kernel qui n'est pas le bon AMHA. Côté applicatif avec gros requis sécurité, cela ferait plus sens.
Historique des modifications :
Posté le 06/09/2024 à 22h08
S'ils veulent refaire un Linux Rust-Inside, bon courage quand même. La maturité de l'infra/chaîne de générations jeunes est un véritable obstacle: Linux n'est pas un projet tout neuf et il faut du stable à ce niveau sinon, au delà des kernel de chapelle d'un kernel c'est de toutes manières les distributions qui ne suivront pas.
On comprends aussi la réserve: Tous les 10 ans on nous annonce le langage qui va être le fossoyeur du C qui est toujours là. Pour du bas niveau, avec des développeurs typés logiciel de base qui doivent déjà se fader la complexité croissante du matériel, je pense que tout langage qui en rajoutera sa couche avec en prime une perte de performance, même faible mais là ou elle est vraiment importante, surtout pour le pb très largement réglé de la mémoire, ne fera pas son trou. C'est aussi un domaine ou la chasse aux dépendances est féroce...
Ils mènent un combat côté kernel qui n'est pas le bon AMHA. Côté applicatif avec gros requis sécurité, cela ferait plus sens.
#2.8
Ils mènent un combat côté kernel qui n'est pas le bon AMHA. Côté applicatif avec gros requis sécurité, cela ferait plus sens.
Mon interprétation de la chose (je ne sais pas si elle est bonne) : le noyau linux serait une superbe publicité pour démocratiser le langage et lui donner une assise stable et une crédibilité qui ferait de lui un langage sûr pour les années à venir (sûr dans le sens de prendre du temps d'investir dedans, je ne parle pas de la sureté inhérente à ce langage pour la gestion de la mémoire par exemple)
#2.13
Puis c'est une méritocratie: Si les mecs croient qu'on va leur dérouler le tapis rouge ils ne tapent pas à la bonne porte je pense. Il va falloir faire leurs preuves à tous niveaux.
#2.14
quand je parlais de "pub", c'était pour Rust, pas pour Linux ^^
#2.9
Justement, Rust est un peu le premier langage a avoir réussi à améliorer des choses niveau perf, et niveau fonctionnalités. D'où son acceptation dans les kernels (Linux, Windows, BSD un jour?)
Certaines constructions sont très intéressantes, sa façon de les compiler plutôt clean.
Franchement, c'est un vrai langage neuf - malgré effectivement une syntaxe dure à appréhender au 1er abord (et au 2nd, et au 3ème...)
"surtout pour le pb très largement réglé de la mémoire"
Bof bof. C'est réglé par de bonnes pratiques difficiles à maintenir/vérifier, soit par des mitigations compilo potentiellement coûteuses.
Mais attention: si Rust règle les problèmes mémoire, il ne règle pas les problèmes de sécu ou de perf liés à l'architecture même du programme ou des protocoles.
#2.11
Certaines constructions sont très intéressantes, sa façon de les compiler plutôt clean.*
Améliorer les choses niveau perf ? Tu peux m'expliquer stp. Parce que niveau perf code, sa syntaxe est un frein à l'optimisation et son temps de compilation (même pas parallélisable) est infecte.
Quelles sont, selon toi, les ajouts utiles de Rust pour dev kernel ? Pour du dev de soft, voir de drivers pas de soucis mais pour des fonctions kernels pures et dures ?
#2.12
#2.18
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla (contrairement a son projet jumeau Servo), car ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique, y compris pour les autres drivers si j'ai bien compris.
J'ai l'impression qu'elle se plaint plus du ton des échanges que de la décision qui, comme tu le dis peut se justifier d'un point de vue risque de régression.
Historique des modifications :
Posté le 09/09/2024 à 09h12
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla, ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique.
Posté le 09/09/2024 à 09h14
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla, ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique, y compris pour les autres drivers si j'ai bien compris.
J'ai l'impression qu'elle se plaint plus du ton des échange que de la décision qui, comme tu le dis peut se justifier.
Posté le 09/09/2024 à 09h16
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla, ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique, y compris pour les autres drivers si j'ai bien compris.
J'ai l'impression qu'elle se plaint plus du ton des échange que de la décision qui, comme tu le dis peut se justifier.
Posté le 09/09/2024 à 09h19
Rust va vers ses 10 ans, c'est vrai que comparé au C c'est jeune, mais il a quand même prouvé sa stabilité. Il n'a absolument pas failli tomber après l'abandon de financement de Mozilla (contrairement a son projet jumeau Servo), car ça faisait longtemps que Mozilla avait rendu le projet indépendant et qu'il était était devenu un support minoritaire.
Certes c'est plus pratique d'avoir un seul langage, mais il faut voir que le Rust ne va pas se retrouver partout dans le code de Linux. Le but du projet et de permettre d'écrire de drivers en Rust. Le noyau reste en C, les driver existants restent en C. Les seules personnes exposées au Rust sont celles qui ont fait le choix de développer leur drivers en Rust.
Elle partage juste sa mauvaise expérience mais, contrairement à Wedson Almeida Filho, elle n'en a pas fait une montagne. Elle a continué a développer son driver malgré le refus du mainteneur qui aurait rendu le fonctionnement plus logique, y compris pour les autres drivers si j'ai bien compris.
J'ai l'impression qu'elle se plaint plus du ton des échange que de la décision qui, comme tu le dis peut se justifier.
#2.19
Je réagis la dessus, car je n'ai pas la même vision que toi.
L'indépendance de Rust est récente. La fondation Rust a été créé il y a un peu plus de 3 ans en 2021.
Pour Servo, pour recadrer, j'ai cru comprendre que nombre de contributeur de Rust faisait tout simplement parti de l'équipe en charge du développement de Servo. Donc Servo abandonné, c'était une bonne partie de contributeurs à Rust qui tombait. Et ça, c'était en 2020 (donc avant la création de la fondation Rust).
Tant que le développeur originel du driver est là, pas de souci. Le jour où il part, s'il y a un bogue à corriger dans un driver, il faut un développeur qui connaisse Rust. Idem, les contributions externes, il faudra connaitre Rust. Aujourd'hui, vu le ratio des dev qui connaisse C par rapport à ceux qui connaisse Rust, ça peut être un véritable frein à la maintenance d'un driver.
#2.20
Au moment de son retrait, Mozilla n'était plus le principal supporter de Rust. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Historique des modifications :
Posté le 09/09/2024 à 10h37
Le projet Rust n'avait pas de fondation pendant longtemps, mais il est devenu hiérarchiquement indépendant de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autre supports sont arrivé. Au moment de son retrait. Mozilla n'étaient plus le principal support financier.
La fondation est arrivée pour prendre les aspects juridiques historiques (marques et logo) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation, comme Mozilla à l'époque n'a pas de pouvoir hiérarchique sur le projet Rust.
En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, on quitté le projet, mais ils ne constituaient plus qu'une petite des contributeurs, la projet a pu l'encaisser.
Posté le 09/09/2024 à 10h42
Le projet Rust n'avait pas de fondation pendant longtemps, mais il est devenu hiérarchiquement indépendant de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autre société ont apporté des contributeurs payée et offert des infrastructure (Azure, AWS, ...). Au moment de son retrait, Mozilla n'était plus le principal support financier.
La fondation est arrivée pour prendre les aspects juridiques historiques (marques et logo) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, on quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, la projet a pu l'encaisser.
Posté le 09/09/2024 à 10h43
Le projet Rust n'avait pas de fondation pendant longtemps, mais il est devenu hiérarchiquement indépendant de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autre société ont apporté des contributeurs payée et offert des infrastructure (Azure, AWS, ...). Au moment de son retrait, Mozilla n'était plus le principal support financier.
La fondation est arrivée pour prendre les aspects juridiques historiques (marques et logo) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, on quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, la projet a pu l'encaisser.
Posté le 09/09/2024 à 10h45
Le projet Rust n'avait pas de fondation pendant longtemps, mais il est devenu hiérarchiquement indépendant de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autre société ont apporté des contributeurs payée et offert des infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal support financier. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, la projet a pu l'encaisser.
La fondation est arrivée pour prendre les aspects juridiques historiques (marques et logo) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 09/09/2024 à 10h45
Le projet Rust n'avait pas de fondation pendant longtemps, mais il est devenu hiérarchiquement indépendant de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autre société ont apporté des contributeurs payée et offert des infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal support financier. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, la projet a pu l'encaisser.
La fondation est arrivée pour prendre les aspects juridiques historiques (marques et logo) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 09/09/2024 à 10h50
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autres sociétés ont apporté des contributeurs payée et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal support financier. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation est arrivée pour prendre les aspects juridiques historiques (marques et logo) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 09/09/2024 à 10h53
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autres sociétés ont apporté des contributeurs payée et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal support financier. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 09/09/2024 à 11h18
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un support majeur en payant les contributeurs a temps plein et en finançant l'infrastructure. Au fur et a mesure d'autres sociétés ont apporté des contributeurs payés et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal support financier. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 09/09/2024 à 14h33
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un supporter du projet, (certes incontournable au début. Il faisant contribuer certains de ces salariés et fournissait l'infrastructure du projet. Au fur et a mesure, d'autres sociétés ont apporté des contributeurs payés et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal supporter de Rust. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 09/09/2024 à 19h59
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un supporter du projet, (certes incontournable au début). Il faisant contribuer certains de ces salariés et fournissait l'infrastructure du projet. Au fur et a mesure, d'autres sociétés ont apporté des contributeurs payés et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal supporter de Rust. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
Posté le 11/09/2024 à 05h55
Il ne faut pas confondre le projet Rust et la Rust Fondation. Le projet Rust est devenu une entité hiérarchiquement indépendante de la fondation Mozilla avant la sortie officielle du langage. Mozilla n'était qu'un supporter du projet, (certes incontournable au début). Il faisait contribuer certains de ces salariés et fournissait l'infrastructure du projet. Au fur et a mesure, d'autres sociétés ont apporté des contributeurs payés et offert accès à leurs infrastructure (Azure, AWS, ...).
Au moment de son retrait, Mozilla n'était plus le principal supporter de Rust. En effet certains employés de Mozilla, dont certains travaillaient aussi sur Servo, ont quitté le projet, mais ils ne constituaient plus qu'une petite partie des contributeurs, le projet a pu le supporter.
La fondation à été créée, assez tard il est vrai, pour reprendre les aspects juridiques historiques (marques et logo notamment) qui étaient encore dans les mains de Mozilla et coordonner les soutiens. Mais dans la pratique le projet fonctionnait sans. La Fondation Rust, comme Mozilla à l'époque, n'a pas de pouvoir hiérarchique sur le projet Rust et n'en est pas propriétaire.
#2.21
Pas tout à fait vrai. La Fondation Rust, si j'ai bien suivi, dispose justement des marques et nom de domaines associés. Elle en est donc propriétaire, légalement parlant.
Mais j'ai bien compris que le côté décisionnel est géré par une équipe (la Rust Team Core existe-elle toujours du coup ?) plus ou moins indépendante vis-à-vis de l'évolution du langage lui-même.
#2.22
Le projet Rust est organisée en différentes team qui gèrent chacune certains aspect du langage (langage,compilateur, lib, doc, ...), la team Core gérant les aspect généraux. l’évolution du langage en lui même est plutôt géré par la Team Language
Historique des modifications :
Posté le 09/09/2024 à 11h12
La fondation est propriétaire de la marque, mais pas du projet. Théoriquement elle pourrait forcer le projet a changer de nom et de logo mais c'est tout. Elle ne peut notamment pas imposer le développement de certaines fonctionnalités, ou imposer des personnes dans les groupes de travail du projet. Comme elle n'est pas propriétaire du code, elle ne peut pas non plus changer les licence du code.
Le projet Rust est organisée en différentes team qui gèrent chacune certains aspect du langage (langage,compilateur, lib, doc, ...), la team Core gérant les aspect généraux. l’évolution du langage en lui même est plutôt géré par la Team Language
#2.23
J'avoue que je ne suis pas Rust au jour le jour, donc c'est pas toujours évident d'avoir toutes les informations ^^
En pratique, la fondation peut quand même faire sacrément pression : vous acceptez ça, ou on vous interdit dorénavant d'utiliser le logo, la marque, et les noms de domaines associés.
De son côté, elle peut forker le projet (il est libre), et faire ensuite évoluer sa marque Rust et le langage associé comme bon lui semble (et d'appeler le langage Rust).
Je ne sais pas si elle est propriétaire ou pas (d'ailleurs, y a-t-il un propriétaire) ? Par contre, elle peut changer la licence. Si je me souviens bien, Rust est sous licence MIT, qui autorise le relicensing tant qu'on conserve les attributions.
#2.24
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.
Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Mais enfin, là on est dans la fiction improbable, le mandat de la fondation est de soutenir le projet Rust.
Historique des modifications :
Posté le 09/09/2024 à 12h17
En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que le l'administratif, et n'a pas les moyen de soutenir un tel projet sans récupérer une grosse partie des équipe.
A la limite si il y avait une dispute terrible dans les équipes du projet qui se séparaient, elle pourrait arbitrer qui aurait le droit de garder nom.
En effet dans le cas de la licence MIT/Apache, la propriété du code n'est pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Posté le 09/09/2024 à 12h26
En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que le l'administratif, et n'a pas les moyen de soutenir un tel projet a moins qu'une partie substanctielle du projet la soutienne dans la démarche.
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.
Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Posté le 09/09/2024 à 12h27
En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que le l'administratif, et n'a pas les moyen de soutenir un tel projet a moins qu'une partie substanctielle des équipes ne la soutienne dans la démarche.
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.
Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Posté le 09/09/2024 à 12h31
En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que de l'administratif, et n'a pas les moyens humains de soutenir un tel projet. Il faudrait qu'au a moins qu'une partie substantielle des équipes actuelles la soutienne dans la démarche.
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.
Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Mais enfin, là on est dans la fiction improbable, le mandat principal de la fondation est de soutenir le projet Rust.
Posté le 09/09/2024 à 12h31
En effet elle peut théoriquement forker et garder le nom, mais sans le projet Rust qui suit ça serait n'irait nulle part. La fondation ne gère que de l'administratif, et n'a pas les moyens humains de soutenir un tel projet. Il faudrait qu'au a moins qu'une partie substantielle des équipes actuelles la soutienne dans la démarche.
A la limite si il y avait une dispute terrible dans les équipes du projet au point qu'ils décident de se séparer, elle pourrait arbitrer qui aurait le droit de garder nom.
Pour la licence, dans le cas de la licence MIT/Apache, la propriété du code n'est, en effet, pas vraiment utile. Si la licence avait été du type GPL, par contre ça ouvrait des opportunités.
Mais enfin, là on est dans la fiction improbable, le mandat de la fondation est de soutenir le projet Rust.
#3
Pour les résumer simplement : 🖕 versus 🖕
#4
Ces déchets s'expriment encore plus violemment dans un contexte/repaire d'expertise, tel qu'un noyau système.
Classique.
#4.1
#4.2
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face, attaques face auxquelles elle n'a plus la force.
Regarde la vidéo : ne te trompe pas de cible.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire par derrière.
L'illustration du courage (ou son manque) moyen. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui n'est rien d'autre, factuellement, que de l'attaque toxique.
Des déchets toxiques. CQFD.
Cela est transférable à bien d'autres domaines, car ça n'est que de l'humain : autres métiers, autres secteurs, dès que des humains se rassemblent (entreprises, associations, groupe informelles, listes de diffusion, équipes sportives, etc.).
Dommage pour le projet que les nuisibles restent et que les forces positives s'en aillent.
Même si c'est souvent comme cela, car les premiers ont les seconds à l'usure. Et personne n'a à être un punching ball.
Historique des modifications :
Posté le 07/09/2024 à 13h31
Ouaip, car il faut appeler les choses par leurs noms.
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, on commence à rentrer dans l'ad hominem.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face et face auxquelles elle n'a plus la force.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui passe par l'attaque toxique.
Des déchets toxiques. CQFD.
Posté le 07/09/2024 à 13h32
Ouaip, car il faut appeler les choses par leurs noms.
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face et face auxquelles elle n'a plus la force.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui passe par l'attaque toxique.
Des déchets toxiques. CQFD.
Posté le 07/09/2024 à 13h32
Ouaip, car il faut appeler les choses par leurs noms.
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face, attaques face auxquelles elle n'a plus la force.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui passe par l'attaque toxique.
Des déchets toxiques. CQFD.
Posté le 07/09/2024 à 13h32
Ouaip, car il faut appeler les choses par leurs noms.
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face, attaques face auxquelles elle n'a plus la force.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui n'est rien d'autre, factuellement, que de l'attaque toxique.
Des déchets toxiques. CQFD.
Posté le 07/09/2024 à 13h33
Ouaip, car il faut appeler les choses par leurs noms.
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face, attaques face auxquelles elle n'a plus la force.
Regarde la vidéo : ne te trompe pas de cible.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui n'est rien d'autre, factuellement, que de l'attaque toxique.
Des déchets toxiques. CQFD.
Posté le 07/09/2024 à 13h34
Ouaip, car il faut appeler les choses par leurs noms.
D'un point de vue pur projet, quand tu bloques de manière destructive, tu gênes, et quand tu fais ça en position de force, c'est encore pire.
Quand tu transformes de faux arguments en attaques, en accusant la personne en face de choses fausses, tu es dans le royaume de l'ad hominem. Ce n'est pas acceptable.
Ça, c'est uniquement sur la base de la vidéo lié par la personne en illustration de ce à quoi elle doit constamment faire face, attaques face auxquelles elle n'a plus la force.
Regarde la vidéo : ne te trompe pas de cible.
Tu imagines bien que l'intensité augmente en privé, et il y a des choses dites/disséminées qui sont certainement encore pire par derrière.
L'illustration du courage (ou son manque) moyen. Comme d'hab'.
On ne parle pas d'évolution de projet, on parle de gens qui ont peur et qui se servent de cette peur comme justification d'une "défense" qui n'est rien d'autre, factuellement, que de l'attaque toxique.
Des déchets toxiques. CQFD.
#5
J'ai l'impression que vous donnez beaucoup la parole aux pro rust et juste l'avis de Linus en réponse un peu argumenté.
Vu la criticité du code et le nombre d'architectures supportées, l'argument du manque de connaissances de l'équipe historique de mainteneurs ne me semble pas déconnant. Comment peuvent ils valider les commits engageant leur responsabilité sans maitriser le langage?
M. Wedson Almeida Filho de Microsoft annonce abandoner sa participation après 4ans, c'était peut être juste un test de motivation de l'équipe kernel Linux?
Historique des modifications :
Posté le 07/09/2024 à 01h39
Bonjour,
J'ai l'impression que vous donnez beaucoup la parole aux pro rust et juste l'avis de Linus.en réponse un peu argumenté.
Vu la criticité du code et le nombre d'architectures supportées, l'argument du manque de connaissances de l'équipe historique ne me semble pas déconnant. Comment peuvent ils valider les commits engageant leur responsabilité sans maitriser le langage?
M. Wedson Almeida Filho de Microsoft annonce abandoner sa participation après 4ans, c'était peut être juste un test de motivation de l'équipe kernel Linux?
#6
Recoder en Rust, c'est la partie fun d'un projet. Maintenir le projet, c'est long et chiant. Et souvent, comme ici, les pro-rust vont arriver avec des propositions de modifs, mais c'est les mainteners qui devront rester sur le long terme et maintenir le code, qu'il n'auront pas écrit, et qu'ils auront même du mal à comprendre.
D'un point de vue long-termiste, c'est pas tenable.
D'ailleurs, je pense que les pro-rust pourront tenter de recréer un noyau from scratch en rust, mais je doute qu'ils arriveront à le maintenir sur le long terme. C'est un boulot ingrat, la maintenance.
Bref, je comprend la frustration des pro-rust, mais au lieu de soumettre du code, ils devraient devenir référent sur des parties du noyau, et maintenir ces parties, en le faisant en rust. Ca, ça pourrait fonctionner.
#6.1
Ou j'ai pas compris votre propos ?
Un mainteneur peut faire de la conversion de code?
#6.2
Si tu connais pas le code actuel, tu peux pas devenir mainteneur. C'est logique. Faut donc maîtriser un module, et donc le language dans lequel il est construit. Ensuite, bloc par bloc, tu peux convertir le code actuel en Rust : c'est une évolution positive (tant que ça reste à features constantes), et tu es mainteneur, donc tu prendras soin de ton code dans le futur.
C'est ça la voie à suivre.
#7
Ça a l'air plus large si on en croit cette citation de Jeremy Soller, créateur de Redox OS (OS codé en Rust) : « Les développeurs Linux sont des mégalomanes pédants et condescendants »
Mais sur cette citation, je dirais qu'il vaut mieux éviter les généralités, d'autant qu'il y a un conflit d'intérêt car en disant ça, ça lui permet de mettre en avant son OS.
Je retiens par contre que faire co-évoluer deux technologies dans le même projet Linux, c'est peut être plus un inconvénient, même ça parait être un avantage pour la "transition". La transition peut en effet ne jamais se terminer.
Le côté redévelopper tout le noyau, ça parait tout aussi insurmontable, mais en fait je pense que ça l'est moins, car il n'y aurait pas forcément besoin de porter tout le code concernant de vieilles architectures, juste le code concernant les architectures récentes. Je trouve que c'est un projet intéressant de tout repenser à zéro. Le fait de tout repenser sur Rust plutôt que d'adapter un noyau initialement pensé pour le C vers le Rust peut éventuellement être moins complexe. Faudrait voir ce que donne des projets comme Redox ou autre.